This invention relates generally to Radio Frequency Identification (RFID) enabled infrastructures, but is intended for any infrastructure dealing with Automated Data Acquisition (ADA), and more particularly to methods and apparatus for filtering duplicate data observations in such an infrastructure.
An enterprise can be defined as a body that comprises a plurality of business units. These business units, can, in turn, have a plurality of sites, and each site may have a plurality of locations. At least one known ADA enabled infrastructure for an enterprise offers architecture in which edge servers capture data deployed at various locations in the enterprise and pass filtered data to one or more enterprise servers responsible for interaction with enterprise applications. The hierarchy of edge enterprise servers can be expanded to ensure that a load is balanced and a single network path is not overloaded with information.
ADA devices are now being developed with new functionality that will handle filtering and data cleansing, and which pass only relevant, intelligently filtered information to upstream systems. Use of these devices will result in lower network traffic with little or no filtering required at the enterprise level. However, enterprise software will still be needed, because apart from filtering, additional tasks such as data collection, formatting, and event generation based upon various business rules must be performed and/or applied to data sent to the back end enterprise applications. In addition, the known current ADA (including RFID) architecture does not support a clustered environment. A clustered environment is an architecture comprising several servers, with the same specific software, that act in concert to share the load of data processing needs.
It has not previously been known that clustered filtering prior to RFID might be needed in some applications. Moreover, because the RFID market is oriented towards an edge-enterprise infrastructure, the need for clustered filtering on centralized software in a clustered environment has not been foreseen.
In at least one known conventional configuration, RFID middleware receives data (hereinafter referred to as an “RFID observation”) from various devices, which may include, but are not limited to, RFID readers, active sensors, and/or PLC devices. (Hereinafter, each of these types of devices will be referred to simply as “RFID readers,” although no loss in generality is intended.) These RFID observations may be received in either or both of two different modes.
In an interactive (request/response) mode, the RFID readers are polled by middleware running on non-RFID application server nodes (i.e., nodes that do not specifically handle RFID observations directly received from RFID readers) at a selected frequency. The RFID readers, in turn, return RFID observation details. Over a cluster of non-RFID application server nodes having the same modules deployed on each node, each non-RFID application server node may selectively poll RFID readers and fetch the RFID observation information for further filtering.
In an asynchronous mode, the RFID reader sends RFID observations without the middleware sending any command to the RFID reader. In this mode, an RFID reader sends observation information to one or more load-balancing devices. The load-balancing device(s) then redirect the request to an RFID application server node in an RFID application server cluster in accordance with configured rules.
In either case, the plurality of application server nodes in a cluster may receive unfiltered RFID observations from the RFID readers. Conventionally, each of the RFID application server nodes filters the RFID observations independently and sends the filtered RFID observations to the backend application running on the corresponding non-RFID application server node. In many cases, this behavior leads to the backend application receiving many duplicate RFID observations as each RFID application server node has filtered the data reads independent of every other RFID application server node. Similarly, if an RFID observation is to be purged from memory, one must ensure that it is purged from the memory of all instances that received the observation information.